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REMARKS/ARGUMENTS 

Reconsideration of this application is respectfully requested. 

In response to the formality-based objection to claims 1-4 and 7-9, these claims have 
been amended so as to more positively state method limitations and thus obviate this ground of 
objection. 

With respect to the formality-based objection to claim 8, the vertical slash has been 
changed to a sloping slash as requested between the words "public" and "private." However, the 
Examiner's interpretation of the separator as being equivalent to "or" is clearly inappropriate. 
As those in the art will appreciate, public key encryption algorithms include a EM of keys: one is 
public and one is private. Obviously claim 8 is referring to the public and private key pair and 
uses typical symbology well understood by those skilled in the art to indicate such. 

In addition to the above-discussed amendments, the entire application has been reviewed 
and amended so as to put it in more traditional U.S. format. This includes claim amendments 
which are hoped to clarify the applicant's claimed invention in view of some apparent 
misunderstandings expressed in the Examiner's comments with respect to prior art-based 
rejections. 

Accordingly, all formality-based issues are now believed to have been overcome in the 
applicant favor. 

The rejection of claims 1-1 1 imder 35 U.S.C. §102 as allegedly anticipated by 
Schweinhart '391 is respectfully traversed. 

Applicant's claimed invention identifies a predetermined number of computers within a 
computer network which satisfy one or more specified conditions. On the other hand, 
Schweinhart is about how to send data over a satellite data communication system. 
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The aim of applicant's invention can be achieved in a basic embodiment, by sending out 
a request message specifying the conditions to be satisfied by any identified computers, the 
request message indicating the total number of computers to be identified, and forwarding this 
message through the network with each computer along the way checking to see if it satisfies the 
specified conditions and if so decrementing the total number of computers to be identified (since 
this computer counts as one of the identified computers so now one less needs to be identified) 
before forwarding it on to a neighbor. 

On the other hand, the aim of Schweinhart is achieved by having a number of satellite 
terminals (ST's) connected to a satellite via uplink and downlink spot beams and a dynamic time 
division multiple access system which co-ordinates when each ST may upload or download 
data. When an ST receives some data for forwarding on to a specific destination reachable via 
the satellite, it places a request for bandwidth in an uplink with the satellite. If the satellite has 
sufficient capacity it sends a rate allocation message back to the ST informing it when it can send 
data in the next uplink fi*ame. 

It is, frankly, impossible for the undersigned to appreciate how Schweinhart might even 
conceivably map onto the claimed invention. Perhaps the Examiner could offer some more 
assistance in helping to understand where he is coming from and to be more specific about what 
features in Schweinhart he thinks maps onto applicant's claimed features? 

There is not even a showing that Schweinhart teaches a method of identifying a number 
of computers within a computer network, let alone a method of identifying a nxmiber of 
computers within a computer network which satisfy one or more specified conditions. Indeed 
there does not appear to be any reference in Schweinhart to any such method. 
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The Examiner refers to paragraphs 49, 50 and 55 as teaching a first computer 
communicating to one or more of the computers in the network a request message which 
includes said one or more specified conditions. However, paragraph 49 describes how a request 
for bandwidth is sent from a ST to the satellite in a "contention channel" (e.g., a simple form of 
ALOHA is used to determine when a ST can send up a bandwidth request and it may therefore 
clash with another request fi-om another ST in which case neither request is received by the 
satellite and neither will therefore be satisfied, instead each ST waits a littie while and then 
attempts to resend the request). Paragraph 49 also explains that the number of contention 
chaimels can be reduced at times when it knows there is a lot of data to be sent (as a result of 
previous successful bandwidth requests from the ST's) and replaced with (non-contention) data 
channels. Since further requests for bandwidth are sent in contention channels, reducing the 
number of contention chaimels should reduce the number of bandwidth requests being 
successfully received by the satellite. Paragraph 50 describes how, when the satellite 
successfully receives a bandwidth request message, it determines if sufficient bandwidth is 
available to satisfy the request and if so it sends a rate allocation message back to the requesting 
ST telling it when to send data according to the request. 

Paragraph 55 describes how a ST can send data in an uplink in the manner specified by 
the satellite in its rate allocation message discussed in paragraph 50. It also explains that data 
channels are non-contentious and that bandwidth requests are sent in contention channels, but a 
release packet (when an ST no longer needs a bandwidth - e.g. because a call it was transmitting 
has now finished) can be sent in the data channel which it is trying to get "released" to avoid 
contention problems. 
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Perhaps the Examiner thinks that a bandwidth request in some way corresponds to 
applicant's claimed request message. However the bandwidth request message does not include 
"a token value which is indicative of a number of computers to be located by the message". This 
is not surprising since the bandwidth request messages in Schweinhart are to request bandwidth, 
not to identify a predetermined number of computers. Nonetheless the Examiner refers to 
paragraph 52 as teaching this feature; or seems to at least (i.e., the Examiner has placed a 
reference to paragraph 52 halfway through the feature "each subsequent computer which 
receives a request message processing the message by performing the following steps"). 

In any event, paragraph 52 simply says that the satellite can refuse to allow a bandwidth 
request by sending a slightly different type of message called an acknowledgement message. It 
also explains what an ST can do if it gets one of these messages. The last part of the paragraph 
explains how a rate request can be de-allocated (released) by the respective ST either sending a 
deallocation message to the satellite or to a ground based management device called the NOCC. 
Nowhere is there any mention of a message of any sort including a token value of any sort, let 
alone one indicating the number of computers to be identified (of course Schweinhart isn't about 
identifying a number of computers so naturally it doesn't describe any such token). 

The Examiner has included in parentheses after referring to paragraph 52: "Schweinhart 
teaches that a number of devices [are] located by [a] message." However, nothing in paragraph 
52 or any other part of Schweinhart teaches any such thing. Furthermore, how is this series of 
words supposed to relate to applicant's claimed feature of a request message containing a token 
value which is indicative of a number of computer devices to be located by the message? 
Schweinhart simply does not disclose any such message. 
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The Examiner again refers to paragraphs 49, 50 and 52, but also additionally to paragraph 
55 with reference apparently to the claimed feature "determining if it [each subsequent computer 
receiving a request message] is able to satisfy the one or more conditions specified in the request 
message." The Examiner then includes in parentheses after this reference the series of words: 
"Schweinhart teaches determining if it is able to satisfy the addresses allocation and 
acknowledgement message specified in the request message." It is imclear what this series of 
words is supposed to mean (e.g., what does "it" refer to) In any event, the bandwidth request 
message does not specify either an "address allocation" - whatever that may be - or an 
"acknowledgement message." So what "request message" is the Examiner referring to here? 
Furthermore, this series of words does not relate to applicant's claimed feature of a computer 
receiving a request message processing it to determine if it (the computer) is able to satisfy the 
one or more conditions specified in the request message. 

The Examiner continues on by referring to paragraph 96 of Schweinhart as allegedly 
disclosing "[each subsequent computer which receives a request message processing the message 
by performing the following step] decrementing the token value within the message". However, 
paragraph 96 only explains how an ST (which is the device which originates the bandwidth 
request messages in Schweinhart and thus cannot be a subsequent computer which receives a 
request message) monitors incoming traffic (from a device which is on the LAN to which the ST 
is connected and which is trying to send data over the satellite communication system) to ensure 
that it stays within the rate allocation profile granted to the ST by the satellite for sending that 
particular batch of data. This is done using a token bucket method which is, of course, well 
known in the art for exactly this purpose. However, the token value is not stored in any sort of 
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request message and certainly not within a bandwidth request message as sent by the ST to the 
satellite. 

The final reference made by the Examiner is to paragraphs 52 and 96 which allegedly 

teach 

"[each subsequent computer which receives a request message processing the message by 
performing the following step] then determining if the token value in the request message 
indicates that at least one further computer device is required to be located and, if so, 
forwarding on the message, or a plurality of daughter messages, on to a subsequent 
computer device or devices within the computer network unless a restriction criterion has 
been met." 

This feature is clearly not taught anywhere in Schweinhart since there is no disclosure 
anywhere in Schweinhart of a request message including a token value specifying the number of 
computers still to be located. 

After referring to paragraphs 52 and 96 of Schweinhart the Examiner again states: 
"Schweinhart teaches - forwarding the message on to devices by satellite unless said packets are 
blocked." But what Schweinhart actually teaches in paragraph 96 is that data packets - not 
bandwidth request messages - are forwarded via the satellite conmiunication system on to the 
destination devices provided they are within the agreed rate allocation profile permitted by the 
satellite and enforced (via the token bucket mechanism) by the ST. 

Given the fundamental deficiencies of Schweinhart already noted above with respect to 
certain features of the independent claims, it is not believed necessary at this time to identify and 
discuss additional deficiencies of this reference with respect to other features of the independent 
claims and/or the rejected dependent claims. Suffice it to note that, as a matter of law, no 
reference can anticipate a claim under 35 U.S.C. §102 unless that reference itself teaches each 
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ft 

and every feature of the rejected claim. Clearly Schweinhart does not do that with respect to 
even a single one of applicant's claims. 

Accordingly, this entire application is now believed to be in allowable condition and a 
formal notice to that effect is respectfully solicited. 
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